A Framework for the Dissemination of Hydrological Models for Non-Expert Users1

Timo Schaﬀhauser

, Daniel Garijo

b,g

, Maximiliano Osorio

, Daniel Bittner

c,f

, Suzanne Pierce

Hernán Vargas

, Markus Disse

and Yolanda Gil

b,e

School of Engineering and Design, Technical University of Munich, Munich, Germany4

Information Sciences Institute, University of Southern California, Marina del Rey, California, United States5

Erftverband, Department for River Basin Management, Bergheim, Germany6

Texas Advanced Computing Center and Jackson School of Geosciences, The University of Texas, Austin, Texas, United States7

Department of Computer Science, University of Southern California, Los Angeles, California, United States8

Institute of Groundwater Management (IGW), Technical University of Dresden, Dresden, Germany9

Ontology Engineering Group, Universidad Politécnica de Madrid, Madrid, Spain10

A R T I C L E I N F O

Keywords:

software metadata

model metadata

model encapsulation

model catalogs

MINT

hydrological models

A B S T R A C T13

Hydrological models are essential in water resources management, but the expertise required to15

operate them often exceeds that of potential stakeholders. We present an approach that facili-16

tates the dissemination of hydrological models, and its implementation in the Model INTegra-17

tion (MINT) framework. Our approach follows principles from software engineering to create18

software components that reveal only selected functionality of models which is of interest to19

users while abstracting from implementation complexity, and to generate metadata for the model20

components. This methodology makes the models more ﬁndable, accessible, interoperable, and21

reusable in support of FAIR principles. We showcase our methodology and its implementation in22

MINT using two case studies. We illustrate how the models SWAT and MODFLOW are turned23

into software components by hydrology experts, and how users without hydrology expertise can24

ﬁnd, adapt, and execute them. The two models diﬀer in terms of represented processes and in25

model design and structure. Our approach also beneﬁts expert modelers, by simplifying model26

sharing and the execution of model ensembles. MINT is a general modeling framework that uses27

artiﬁcial intelligence techniques to assist users, and is released as open-source software.28

ORCID(s):

First Author et al.: Preprint submitted to Elsevier Page 1 of 37

Short Title of the Article

Highlights30

• An approach that facilitates hydrological model dissemination from expert modelers to non-experts31

• Software engineering methods are proposed to simplify model complexity by creating software components32

• Non-experts can easily modify selected parameters and execute models provided by experts33

• Our approach makes models more ﬁndable, accessible, interoperable, and reusable in support of FAIR principles34

• Various applications beneﬁted from this approach within the MINT framework35

First Author et al.: Preprint submitted to Elsevier Page 2 of 37

Short Title of the Article

1. Introduction36

Hydrological models (HMs) are commonly used for water resources management and are mainly developed and37

used by expert researchers or engineers working in the water sector. The results of HMs are important and considered38

in decision-making processes of government agencies (Ruiz-Ortiz et al., 2019; Andreu et al., 1996). HM applications39

include estimation of water availability (Döll et al., 2003), development of water management strategies (Haasnoot40

et al., 2011), ﬂood risk assessment (Merz et al., 2010), climate impact analysis (Krysanova and Hattermann, 2017;41

Lobanova et al., 2018; Hattermann et al., 2018), solute transport (Konikow, 2010; Morales et al., 2010) and spatial42

characterization of hydrological system variables such as soil water content (Brocca et al., 2017), desalination and43

industrial wastewater treatment (Panagopoulos, 2022) as well as groundwater heads (Reinecke et al., 2019). HMs44

vary widely in terms of their mathematical description of prevalent hydrological processes and their spatial model45

structure, ranging from lumped conceptual models (Bittner et al., 2018; Booij and Krol, 2010) to distributed physical46

models (Brunner and Simmons, 2012; Newman et al., 2017).47

A fundamental understanding of hydrological processes is needed in order to reasonably set up a hydrological model48

for a new region or modeling problem. This may become an obstacle for the use of HMs by decision-makers and other49

users (Lüke and Hack, 2018). In practice, model results are presented to decision-makers as a summary focusing only50

on a few speciﬁc variables of interest, such as streamﬂow or groundwater heads. The interests and requirements of51

decision-makers and various stakeholders can diverge widely from what may be hydrologically interesting. Decision52

makers in water resources management are usually interested in the assessment of the water balance, primarily the53

availability of water in space and time. HMs allow a holistic view on the components of the water cycle, from which54

insightful information, e.g. limiting factors in space and/or time, can be derived. These variables do not necessarily be55

restricted to water availability, but could also refer to evapotranspiration, soil water or precipitation. Miscommunication56

between science and non-expert groups is therefore not a rarity (Timmerman and Langaas, 2005). This increases the57

“science-policy gap" due to diﬀerences in the level of knowledge between the information producer and receiver58

(Bernstein et al., 1993; Bradshaw and Borchers, 2000). Consequently, it is a challenging task for modelers to provide59

information that is practically usable and interpretable by a broader community of end users (Fatichi et al., 2016).60

Ideally, HMs would be accessible to any potential users so that they are able to test diﬀerent decisions and sce-61

narios themselves. Potential users who are not hydrology experts can include data analysts, decision-makers, and also62

scientists in other disciplines who aim to incorporate water-related topics into their models. In situations where dif-63

ferent disciplines need to work closely together, and where models from diﬀerent areas such as economics, hydrology,64

climatology or ecology may need to be integrated, further obstacles often emerge, as HMs often need to be designed,65

exchanged and run by diﬀerent user groups. Moreover, several models with overlapping features may be available, and66

selecting an appropriate model for a task can be challenging even for experienced modelers (Surﬂeet et al., 2012). In67

First Author et al.: Preprint submitted to Elsevier Page 3 of 37

Short Title of the Article

addition, enabling diﬀerent capabilities of a model can lead to diﬀerent data and input requirements.68

Even for hydrology experts, it can be diﬃcult to understand how processes are represented in diﬀerent HMs, making69

comparison studies very time-consuming. HMs tend to have special computational requirements and use heterogenous70

ﬁle formats for spatio-temporal data, so that data pre-processing usually requires basic programming skills. Additional71

technical challenges arise when HMs require diﬀerent operating systems or complex model conﬁgurations, which can72

limit the applicability and transferability of models even for hydrology experts. Therefore, there is a great need for73

new approaches to facilitate the dissemination of HMs to users who lack the expertise to develop them but are invested74

in using them for decision-making purposes.75

Over the last few decades, eﬀorts have been made to make HMs more accessible by integrating them into Geo-76

graphic Information Systems (GIS) (Bittner et al., 2020; Rossetto et al., 2018; Refsgaard et al., 2010). In this regard,77

GIS-based interfaces to HMs often act as an essential component of a Decision Support System (DSS) (Lautenbach78

et al., 2009; Pezij et al., 2019; Zhang et al., 2014).79

Executable and well-structured DSSs make HMs even applicable by non-expert groups, but DSSs usually lack80

transferability as they are strongly tailored to the individual conditions of a deﬁned case study. An example of how81

DSSs are often developed in the course of a project to combine diﬀerent stand-alone software tools can be found in82

(Kinzelbach et al., 2021). However, a limitation of many DSS is that they are desktop-based and therefore show limited83

accessibility. Moreover, they often focus on one area, such as groundwater and even on one model and are thus lacking84

interoperability. GIS-based interfaces have been used in the Soil Water Assessment Tool (SWAT) (Arnold et al.,85

1998), the Free and open source software tools WATer resources management system (FREEWAT) (Koltsida and86

Kallioras, 2019) or the Hydrologic Engineering Center - Hydrologic Modeling System (HEC-HMS) (US Army Corps87

of Engineers, 2000), but models must be set up from scratch by experienced users. Furthermore, these platforms only88

include a single HM, while users often want to use several HMs to compare their results. Consequently, initiatives like89

the Community Surface Dynamics Modeling System (CSDMS) (Peckham and Syvitski, 2007; Peckham et al., 2013),90

the Earth System Modeling Framework (ESMF) (Hill et al., 2004) or the HydroShare platform (Horsburgh et al., 2016)91

have already taken a step forward to provide and combine multiple models from diﬀerent disciplines. CSDMS and92

ESMF include the dissemination of ﬁnal and calibrated models combined with their results from a variety of disciplines93

in the ﬁeld of Geo- and Earth Science (Overeem et al., 2013; Collins et al., 2005; Keller et al., 2014), while HydroShare94

is explicitly designed for the exchange, storage or management of hydrological datasets and models (Gan et al., 2020).95

However, these eﬀorts are focused on users who are modeling experts pursuing science research, rather than non-expert96

users.97

In order to ease the dissemination of expert models to non-experts, our previous work introduced the Model IN-98

Tegration Framework (MINT) (Gil et al., 2018, 2021). MINT deﬁned the components and interfaces needed to assist99

First Author et al.: Preprint submitted to Elsevier Page 4 of 37

Short Title of the Article

expert modelers when setting up pre-existing HMs for non-experts. But adding new HMs to the framework required100

advanced software engineering skills, making it challenging for expert users to contribute. This paper builds on our101

previous work, with the following novel contributions:102

1. A methodology that follows principles of software engineering to create software components for HMs with a103

simple invocation function with pre-set inputs and parameters, capturing metadata about the model that can be104

used to provide guidance to non-expert users.105

2. An implementation of this methodology that guides expert modelers to create model components, integrated in106

the Model INTegration Framework (MINT) (Gil et al., 2018, 2021).107

3. Two use cases that demonstrate the use of this methodology and implementation for two models that diﬀer in108

terms of hydrological processes they consider, as well as in terms of their individual code structure: SWAT109

(Arnold et al., 1998) and MODFLOW (Harbaugh, 2005).110

This methodology makes models more ﬁndable, accessible, interoperable, and reusable in support of FAIR prin-111

ciples (Wilkinson et al., 2016).112

The paper begins with a description of our proposed methodology for creating software components for models113

(Section 2). Next, in Section 4, we illustrate how the methodology is implemented in the MINT Model Insertion114

Checker, a standalone application designed to guide users through the proposed methodology steps. Section 5 describes115

two examples that follow our methodology to deliver two diﬀerent HM conﬁgurations for two diﬀerent regions of the116

globe. Section 6 shows how each of these conﬁgurations can be accessed and run in the MINT platform. Section 7117

discusses the main advantages and limitations of our approach, and Section 8 presents conclusions and future work.118

2. Background119

HMs diﬀer in the way they conceptualize the characteristics and ﬂow processes in a natural system. As a result,120

HMs usually have dozens of parameters and input ﬁles which vary across diﬀerent scenarios. For example, models121

like SWAT may use an input ﬁle with snowmelt observations in regions with mountains but may not take snowmelt122

into consideration if there are no mountains around the basin of interest. Expert hydrologists, who we will refer to here123

as modelers, need to make decisions about which hydrological processes and corresponding parameters are relevant124

to the intended non-expert users (e.g., decision-makers, analysts, researchers with expertise in other areas or domains,125

students in training or citizens who are active in non-governmental organization), who we will refer to as users.126

2.1. Software Components127

Encapsulating software into portable components allows other users to easily run software on their own machine128

without worrying about the environment and set up needed (Boettiger, 2015; Kurtzer et al., 2017) Following well-129

First Author et al.: Preprint submitted to Elsevier Page 5 of 37

Short Title of the Article

established component-based software engineering principles, we aim to create self-contained software components130

that only reveal functionality that is of interest to third-party users. This is important because scientiﬁc software com-131

ponents are often implemented in large packages or libraries that can be used for various steps such as data preparation132

and visualization in addition to writing software to simulate speciﬁc processes (such as atmospheric dynamics for133

climate models, runoﬀ and inﬁltration for hydrology models, fuel density for ﬁre modeling, etc.).134

Software packages can be quite overwhelming for users, even when they are familiar with the scientiﬁc domain for135

which the package was written. Usability becomes even more challenging for users outside of the domain, although136

these users are precisely the ones who may beneﬁt the most from the results of the respective packages.137

Existing graphical user interfaces (GUIs) and GIS systems are often often diﬃcult to reuse from other programs.138

User interfaces usually have a speciﬁc function to call the software with a button, using a form which users operate139

to deﬁne speciﬁc parameters (typically the most relevant ones). That function call (sometimes called a command140

line invocation) is reusable from diﬀerent programs, provided that the software tool can be run from a machine with141

its speciﬁc execution environment. The function call uses inputs that can be provided when invoking the software142

component (as it is done in a user interface where the values for some input parameters are set). Other inputs can be143

pre-set within the component (including data ﬁles) if there are no reasons for third party users to change them given a144

speciﬁc use case.145

A software component corresponds to a single invocation function for software. Given a sophisticated software146

package with multiple purposes, a software component may be created to include only certain processes and variables,147

a speciﬁc pre-processing step, or a speciﬁc visualization. For example, a hydrology model software may be pre-set to148

be applicable to hot arid regions only and ignore the processes (and therefore inputs) describing snowmelt.149

2.2. Model Conﬁgurations & Encapsulation150

We use the term model encapsulation to refer to the process of creating easy-to-use self-standing executable soft-151

ware components from models for a target scenario. We refer to these software components as model conﬁgurations.152

Expert modelers are responsible for designing these model conﬁgurations for a region by identifying the key parame-153

ters that non-experts should be able to modify. Model conﬁgurations declare only those relevant parameters or input154

ﬁles that users should be able to change so the model conﬁguration can be easily set up and run to explore diﬀerent155

scenarios.156

The remainder of this section illustrates model conﬁgurations through a simple example, introduces key concepts157

in model encapsulation, and describes the main steps of our methodology.158

First Author et al.: Preprint submitted to Elsevier Page 6 of 37

Short Title of the Article

Figure 1: Overview of two model conﬁgurations. The ﬁrst conﬁguration (left) exposes snow

(01.sno) and topographic input ﬁles (01.sub) associated with spring melt. Two speciﬁc

parameters of the 01.sno ﬁle are exposed, namely snowmelt temperature and maximum

melt factor, as well as the simulation time as general boundary conditions (stored in

ﬁle.cio). Additional exposed ﬁles include output.rch ﬁle storing streamﬂow, as well as the

output.sub ﬁle to make snowmelt accessible. The second conﬁguration (right) focuses on

a smaller basin inside the country, and it is limited to discharge. The simulation time and

the maximum melt factor are pre-set with a meaningful default value.

2.3. Model Conﬁgurations: An Example159

For illustration purposes, let us consider Alice, an expert hydrology modeler, and Bob, a decision-maker with160

little hydrological expertise. Bob needs to regulate policies for the water budget at a country scale, and therefore he161

is interested in obtaining a rough estimate on water availability during the Spring season. In particular, Bob seeks to162

First Author et al.: Preprint submitted to Elsevier Page 7 of 37

Short Title of the Article

understand: 1) whether the water demand of speciﬁc crops can be met under diﬀerent assumptions and 2) the impact163

of runoﬀ for energy production, i.e., from hydro-electrical plants. Given her expertise, Bob asks Alice to provide an164

environment where he can run model simulations according to his requirements.165

Alice anticipates that Bob may want to modify some of the simulation parameters aﬀecting snowmelt, the dom-166

inant runoﬀ component and source of water in Spring. A shift in the onset and duration of snowmelt usually aﬀects167

the temporal water availability of the agricultural and energy sector. Alice decides to use the SWAT model and creates168

two model conﬁgurations to predict streamﬂow as a proxy representation for water availability. The ﬁrst model con-169

ﬁguration is designed at the country level, letting Bob modify the snowmelt temperature and the maximum possible170

snowmelt to explore the eﬀects on agriculture (e.g., what crop yield can be achieved by diﬀerent crops). The second171

model conﬁguration focuses on a small basin located in the Northeastern region of the country, in order to study the172

conditions and eﬀects of snowmelt for a potential small hydroelectric power plant. Both model conﬁgurations ﬁrst173

undergo a strict and rigorous calibration and validation procedure by Alice, a necessary expert step to ensure a reliable174

baseline for the further usage. The calibration and validation serve as fundamental steps to provide robust and credible175

models.176

Figure 1 shows an overview of the model conﬁgurations prepared by Alice, with the country-level conﬁguration on177

the left and the basin conﬁguration on the right. Each conﬁguration has one or multiple inputs and outputs, representing178

the ﬁles accepted and produced by a conﬁguration. We use the term parameters to refer to values a user may be179

interested in changing in a model, such as snowmelt temperature, even if these values are declared within conﬁguration180

ﬁles. We consider as parameters hydrological or process-based variables, together with temporal information such as181

simulation length or time step, here referred to as boundary conditions (BC). A code wrapper captures how to invoke a182

model conﬁguration by indicating how the command line should be invoked, and speciﬁes any ﬁxed values of inputs.183

When creating a model conﬁguration, a modeler like Alice may have to choose which of the inputs or parameters184

should be adjustable by the ﬁnal user, among the dozens or hundreds of input ﬁles and parameters HMs have. We use the185

term expose to indicate that a parameter or input ﬁle can be adjustable by a user in a model conﬁguration. For example,186

SWAT contains hundreds of ﬁles, but Alice estimates that the relevant ones for the country-level conﬁguration are two187

input ﬁles with snow and elevation information. As shown in Figure 1, the input ﬁle containing snow information188

further includes the parameters that will be exposed to users, namely snowmelt temperature and the maximum melt189

factor of snow. Adapting the threshold temperature when snow begins to melt is an easy way to shift the melt season190

within the country. The second parameter provides information on the amount of snowmelt one could expect. Alice191

thus provides a meaningful range of values, within which Bob is able to increase or decrease the amount of snowmelt.192

In addition, Alice decides to expose a ﬁle that includes general information on BC like the time for which the model193

was set up or its temporal resolution, daily in this case. Thanks to this information, Alice expects Bob to be able to194

First Author et al.: Preprint submitted to Elsevier Page 8 of 37

Short Title of the Article

Table 1

Overview of terminology used that has a speciﬁc deﬁnition in that paper, but might have

an ambiguous use outside our work.

Term Description

Model encapsulation Process of creating easy-to-use and independent software components (e.g. from a

model)

Model conﬁguration Abstracted version of a model which considers only relevant inputs, outputs and

parameters that are adjustable. Model conﬁgurations represent software components

Boundary condition General information of a model such as temporal information

Parameter Hydrological or process-based variable where users might be interested in to change

Expose Indicates that a speciﬁc parameter or ﬁle is adjustable by the user

Expert Hydrology expert used to modelling

User A non-expert in the ﬁeld of modelling, such as for example citizens, decision makers,

researchers from other ﬁelds, analysts

Wrapper Captures how to invoke a model conﬁguration and speciﬁes ﬁxed values

compare the eﬀects of a very high and a very low value for snowmelt temperature as well as the maximum melt factor195

on the water availability.196

As for the basin conﬁguration, Alice is familiar with the area from her previous work. Therefore, she decides to197

set up all default values of the model according to her knowledge of the region. She exposes snowmelt temperature198

by making only this parameter available in the basin conﬁguration. This conﬁguration is more restricted, but more199

precisely tailored to the region at hand. Therefore, this model conﬁguration is simpliﬁed by allowing Bob to only200

modify snowmelt temperature. Hence, Bob can now obtain alternative estimates with respect to the accumulation of201

snow during winter, which is then available as melt water. This enables the decision-maker to infer whether a small202

hydropower plant might be of value or not or how much energy could be produced under various snowfall conditions.203

In summary, with these model conﬁgurations the modeling expert is able to hide the complexity of a general204

model exposing only what is relevant for a country and its hydrology, narrowing it down to a much more usable model205

component for other users to explore scenarios and make decisions accordingly. It should also be mentioned that Bob206

doesn’t necessarily must be a decision maker. However, he could also be an interested member of a NGO which deals207

with environmental issues for example or just an interested citizen increasingly aﬀected by hydrological events such208

as drought or heavy rain.209

Table 1 provides an overview about the terminology we use in this paper, especially to distinguish terms which might210

ambiguous and are used diﬀerently in other ﬁelds.211

First Author et al.: Preprint submitted to Elsevier Page 9 of 37

Short Title of the Article

Table 2

Overview of the main steps of our proposed model encapsulation methodology.

Description Result

Step 1: Start a New Environment • Modeler indicates a working folder (it

may be empty)

• System prepares a basic execution en-

vironment (e.g., Unix and Python)

The system populates the component folder

structure, including a setup ﬁle containing

information on the target model component

and creating an empty software container

Step 2: Trace Execution Dependencies • Modeler runs a test execution

• System detects dependencies to exe-

cute the model and adds them to the

container

Container that includes execution

dependencies for the model run

Step 3: Expose Parameters • Modeler indicates user-adjustable pa-

rameters to be exposed

• Modeler speciﬁes default values

• System stores parameter exposure

and links to conﬁguration ﬁles

File containing parameter information

Step 4a: Expose Input Files • Modeler indicates input ﬁle types ex-

pected by the conﬁguration

File containing the input ﬁle selection

Step 4b: Expose Output Files • Modeler indicates output ﬁle types

produced by the conﬁguration

File containing the output ﬁle selection

Step 5: Create Wrapper Script • Modeler reviews the execution shell

script created by the system to run

the new model component according

to the speciﬁed settings, and does a

test run of the component

• System ensures that the test run com-

pletes successfully, and uses the pro-

vided input/output description, pa-

rameter settings and shell script to

create the model component as a con-

tainer with the required dependencies.

Creation of subfolders and ﬁles with

encapsulation and execution information

Step 6: Model Upload • System uploads the model component Registration of model component in

container and code repositories and model

catalog

3. A Methodology for Model Encapsulation212

We propose a methodology for creating model conﬁgurations. Our methodology requires expert modelers to de-213

termine the main parameters and input ﬁles that need to be exposed for a given executable model, including steps for214

guiding and testing the ﬁnal model conﬁguration so other users can use it eﬀectively. Our methodology comprises six215

main steps: Start a New Environment, Trace Execution Dependencies, Expose Parameters, Expose Input & Output216

Files, Wrap Execution, and Model Upload. Table 2 provides a summary of all steps, which are further described here.217

Step 1: Start a New Environment: Modelers start by specifying the location for the folder structure of the new218

model component they want to create. This should be started in a “clean" computing environment, free from other219

First Author et al.: Preprint submitted to Elsevier Page 10 of 37

Short Title of the Article

software dependencies installed on the local machine. For example, if a model is available in Python, starting in a220

clean environment makes it easy to isolate the model needs from other Python libraries installed in the machine for221

other purposes. This can be achieved by using virtual environments, that create a clean Python installation with no222

installed package dependencies. In our methodology we adopt software containers, a common approach to capture223

computational environments. Software containers enable capturing the dependencies of a software component at the224

operating system level (i.e., including not only the dependencies of a software component, but all the system depen-225

dencies as well), hence ensuring that it can be run in other environments.226

Because containers can be complicated to set up and use for non-computer scientists, our system will be automati-227

cally creating the container and installing the dependencies and ﬁles needed to run the model. The modeler can see228

everything that the system is adding in the folder that they speciﬁed.229

Step 2: Trace Execution Dependencies and Run Model: Once an environment has been set up, the dependencies230

needed to install the model must be incorporated into the environment. This includes compilers, system libraries, and231

other ﬁles. The modeler carries out a test run that is representative of how the model conﬁguration will be used. During232

the run, the system automatically detects the model input, conﬁguration, and output ﬁles used by the model during the233

run. This information is added to the container environment and used by the system in subsequent steps in order to234

assist the modeler to specify inputs and outputs.235

Figure 2: An illustration of how the snowmelt temperature parameter (SMTMP) of a

SWAT model is exposed so it is accessible for users to adjust for diﬀerent scenarios: a)

shows the original .bsn ﬁle with the default value assigned to SMTMP, b) shows how

the default value is exposed so it can be changed by a user when running the model

conﬁguration.

Step 3: Expose Model Parameters and Deﬁne Conﬁguration Files. Most HMs have dozens of parameters and BCs236

First Author et al.: Preprint submitted to Elsevier Page 11 of 37

Short Title of the Article

which specify constants like hydraulic conductivity, bulk density, or the general settings of the simulation. Within237

this step, modelers have to deﬁne which of these parameters and BCs they want to expose to users in the new model238

conﬁguration. For example, the CN2 (Curve Number II) parameter of SWAT is usually one of the parameters which239

is typically changed during the model setup and calibration (the process of estimating relevant parameters and their240

corresponding values) and might be a useful parameter to expose in a model conﬁguration.241

HMs usually adjust numerical values for their simulations in two diﬀerent ways: 1) with the invocation command used242

to run the model; or 2) through conﬁguration ﬁles that can be edited directly or accessed via user interfaces. If a ﬁle243

is used, it needs to be speciﬁed by the modeler. Fig. 2 illustrates this with an example of how the snowmelt base244

temperature parameter is exposed for the SWAT hydrology model (SMTMP) through a conﬁguration ﬁle.245

Step 4: Expose Model Inputs and Outputs. Next, modelers have to decide which input and output ﬁles they want to246

expose, which depends on the intended use cases that users will want to simulate. As with parameters and BCs, expert247

modelers usually provide the relevant input ﬁles required by a model. Likewise, models produce all sorts of output248

variables, and for a given conﬁguration only a certain subset of outputs may be relevant for the intended use cases. For249

instance, a modeler may expose only output ﬁles containing drought-related variables such as evapotranspiration and250

soil moisture.251

Step 5: Create a Wrapper Script. Once the parameters, BCs and ﬁles to be exposed have been speciﬁed, the next252

step is to write a shell script which captures how to run the model conﬁguration. We refer to this script as the wrapper253

script, as it wraps the model conﬁguration as an executable component. The wrapper script will make sure that the254

component can run with the inputs and outputs selected by the modeler, and may include pre-set ﬁles or values for other255

inputs and parameters. In order to verify that the model works appropriately with the wrapper script, it is necessary256

for the modeler to provide sample input ﬁles which are used in a test run. If everything works successfully, the model257

conﬁguration is completed and will be executable in other computational environments.258

Step 6: Upload the model conﬁguration. The ﬁnal step is to deposit the model conﬁguration in shared repositories.259

First, the script and test data used to wrap up the model conﬁguration should be deposited in a code repository. Second,260

an archival version of the model software code must be created in a code repository, to ensure that that version can261

always be accessed by users in the future. Third, the container environment should be uploaded to a container registry.262

Finally, the model conﬁguration should be uploaded to a model catalog, with proper model conﬁguration metadata263

provided by the modeler to enable discovery and reuse.264

4. Methodology Implementation265

We implemented our methodology in the MINT Model Insertion Checker (MIC), a standalone application devel-266

oped to guide users through the process of creating new model conﬁgurations. MIC performs all the steps of our267

First Author et al.: Preprint submitted to Elsevier Page 12 of 37

Short Title of the Article

Figure 3: Overview of the methodology steps as well as the resources created by each

step.

methodology in a semi-automated manner, integrating the results with commonly used software and container image268

repositories such as GitHub and DockerHub. MIC also integrates new model conﬁgurations and the metadata in the269

MINT modeling framework and its model catalog (Garijo et al., 2019). MIC is implemented as a Unix-based tool that270

runs in the command line, and is available as open source software (Osorio et al., 2022).

A step by step tutorial is271

Software respository is at https://github.com/mintproject/mic/ with documentation at (https://mic-cli. readthedocs.io/e

n/latest/overview/)

First Author et al.: Preprint submitted to Elsevier Page 13 of 37

Short Title of the Article

available online

to help users and disseminate the steps of our methodology.272

Figure 3 provides an overview on how MIC implements all the steps of our methodology, capturing the main273

software dependencies, input, parameters and generated ﬁles, and showing how the methodology steps are related274

to one another. MIC guides users through the six steps outlined in our methodology. It starts with a blank Unix275

environment, generated with a basic Docker image, where users are asked to install and run their model from scratch276

(step 1). Once a sample run is ﬁnished, MIC tracks which ﬁles have been used and generated using ReproZip (Rampin277

et al., 2016), an application designed to trace all dependencies and system calls of a program (step 2). Using the278

output from ReproZip, MIC drafts an initial component, based on the inputs and outputs detected in the test run. Next,279

MIC works with the modeler to get information about the inputs, parameters and BCs of HMs should be exposed280

in the model conﬁguration, among all the candidates detected automatically (steps 3 and 4). The preparation of the281

conﬁguration ﬁle is one of the few activities that has to be carried out manually by the modeler, as it involves information282

highly dependent on the use cases required by the intended users. For example, SWAT may be used to create multiple283

conﬁgurations depending on whether modelers need to expose snowmelt temperature, hydraulic conductivity or a factor284

to delay groundwater ﬂow. The parameters and BCs exposed with MIC will be adjustable by users when running the285

model conﬁguration. If one of the exposed parameters or BCs are stored in a conﬁguration ﬁle, an additional step is286

required to indicate where to replace the target value in that ﬁle. An example can be seen in Figure 2, where snowmelt287

temperature in SWAT is exposed through the SMTMP parameter which can be provided by users at runtime. All the288

information provided to MIC is stored in a MIC settings ﬁle that can be inspected and edited by modelers at any time,289

e.g., to change default values for parameters or to make adjustments on what is exposed to users.290

Once all the inputs, outputs, parameters and BCs form a speciﬁc model conﬁguration are set, MIC will prompt291

users to perform a test run using all default values. MIC automatically creates an execution wrapper script (step 5) and292

runs the model using the local environment created earlier in the second step. If successful, the model conﬁguration293

is ready to be run by others, and MIC will prompt users to double check if the results from the execution are correct.294

As a ﬁnal step, MIC saves the model conﬁguration (step 6) including:295

1. the computational environment used in the test run, saved as a Docker image in DockerHub

296

2. the wrapper script and settings ﬁle containing the exposed inputs, outputs, parameters and BCs. MIC will297

store these ﬁles in a new GitHub repository, owned by the modeler who created the model conﬁguration298

3. basic metadata about the model conﬁguration, including its main title, description, version of the model, geo-299

graphic location, execution details and brief parameter and input descriptions. These metadata are submitted to300

the MINT model catalog, producing the results shown in Figure 4.301

https://mic-cli.readthedocs.io/en/latest/model_configuration/03a-step1/

https://hub.docker.com/

First Author et al.: Preprint submitted to Elsevier Page 14 of 37

Short Title of the Article

Figure 4: An example of how a model conﬁguration is used by modelers and users: a) the

modeler provides all the metadata, including the parameters and ﬁles exposed to the user,

and specify default values for some of the parameters so end users only need to adjust one

of them (snowfall temperature); b) end users wanting to use that model component can

specify diﬀerent values of the parameters and submit model runs that correspond to the

scenarios they want to explore.

First Author et al.: Preprint submitted to Elsevier Page 15 of 37

Short Title of the Article

In the following sections we provide several screenshots of MIC to familiarize the reader and potential users with the302

platform. Figure 4 shows an example of how the model conﬁguration can be accessed by a user after being created with303

MIC. Figure 4 a) depicts a model conﬁguration where four parameters are exposed (i.e., minimum and maximum melt304

factors, snowfall temperature and snowmelt temperature) out of the dozens of parameters that are available in SWAT.305

Figure 4 b) shows an example where only one of the four parameters (snowfall temperature) may be changed by users306

when running a second, diﬀerent conﬁguration of SWAT (the other three parameters are ﬁxed). Both conﬁgurations307

of the model are integrated in the MINT framework, where they can be executed through a GUI.308

5. Creating Model Components: Two Practical Use Cases309

In this section we showcase our methodology by encapsulating two diﬀerent and widely used hydrological models,310

i.e, SWAT and MODFLOW, using MIC to create model components and running them in the MINT platform. By311

pointing out the speciﬁc diﬀerences of SWAT and MODFLOW, we illustrate the main concepts of our methodology312

as well as the technical features of MIC that facilitate model dissemination for any type of HM. We show model313

conﬁgurations for SWAT and MODFLOW for two diﬀerent case studies. Each case study was deﬁned prior to our314

work by a diﬀerent research group working with stakeholders in diﬀerent regions of the world.315

5.1. SWAT: Background and Model Structure316

The Soil Water Assessment Tool (SWAT) is a semi-distributed, time-continuous model developed by the Blackland317

Research & Extension Center of the United States Department for Agriculture (USDA) (Arnold et al., 1998). SWAT318

is based on the concept of the Hydrologic Response Units (HRU) and was originally developed to assess the impact of319

land management practices in large watersheds, while the applications nowadays range from water quality or sediment320

transport studies up to snow-hydrological in basins all over the world Arnold and Fohrer (2005).321

HRUs are the smallest spatial unit within the model and deﬁned on the subbasin scale, a further subdivision of the322

watershed. However, HRUs are not spatially located and are formed by unique combinations of land use, soil and323

slope within each subbasin to consider spatial heterogeneity. The HM is organized by input ﬁles grouped by diﬀerent324

processes or characteristics, such as land management or soil inputs, for the individual spatial units. Besides, the325

model includes few general ﬁles where basic settings can be done. SWAT separates its calculations in a land and a326

water phase. It ﬁrst calculates all loadings for the HRUs in each subbasin, which are then transferred to the stream. In327

a second step the in-stream processes, covering routing processes as well as chemical processes, are calculated.328

5.2. MODFLOW: Background and Model Structure329

The MODular Finite-diﬀerence FLOW model (MODFLOW), is a fully-distributed and physically-based ground-330

water model, developed by the United States Geological Survey (Harbaugh, 2005; Hanson et al., 2014). MODFLOW331

First Author et al.: Preprint submitted to Elsevier Page 16 of 37

Short Title of the Article

is organized in modules, which allow for user customization of speciﬁc case studies (i.e., by selecting only those332

modules that are relevant). For instance, a module can represent diﬀerent solvers for the groundwater ﬂow equation.333

Moreover, various modules exist to account for diﬀerent hydrological processes in a natural system, e.g., stream ﬂow,334

evapotranspiration or groundwater recharge. Given the grid-based nature of the model, several modules can be cou-335

pled by providing grid coordinates in the input ﬁles. If speciﬁc modules should be used in a model run, an input ﬁle is336

required for each respective module. These input ﬁles are ASCII ﬁles, either organized in a table format or grid-based.337

All modules to be used for a model simulation have to be included in a conﬁguration ﬁle, i.e., a name (.nam) ﬁle.338

Depending on the interaction of diﬀerent hydrological processes, MODFLOW solves the groundwater ﬂow equation339

and provides water budgets for each pre-deﬁned discrete time step in an output ﬁle, the list (.lst) ﬁle.340

5.3. Model Implementation341

In the following we describe how our methodology, described in section 3, is implemented for two diﬀerent HMs,342

namely SWAT and MODFLOW. Most of the steps are similar for both models (and to other HMs), despite how diﬀerent343

their software and approach are. Therefore, we focus on demonstrating how users can describe the models following344

our methodology using diﬀerent use cases.345

5.3.1. Case Studies346

The location of our study areas and their geographical characteristics are illustrated in Figure 5. Our case studies347

focus on two very distinct hydrological systems: the Naryn River in Kyrgyzstan for SWAT and the Barton Springs348

segment of the Edwards aquifer in Texas for MODFLOW. For each case study we emphasize which part of the proposed349

methodology is similar and where diﬀerences occur, which mainly concern the exposed inputs and outputs in the350

respective model conﬁgurations. The BCs, such as simulation period and time step, have been set by experts for both351

case studies. The target user groups of both cases are non-expert analysts and decision-makers. Our intention is to352

grant the respective users access to the model conﬁgurations, so that they are able to run alternative scenarios on their353

own. A summary of the case studies can be found in Table 3.354

5.3.2. Snow dynamics in the Naryn Basin - Case Study355

Our ﬁrst case study focuses on a part of the Naryn Basin located in Kyrgyzstan, where high ﬂow occurs mainly356

in Spring and Summer due to snow and glacier melt. In contrast, low ﬂow phases are mostly restricted to the winter357

season. The basin belongs to one of the headwater streams of the Syr Darya, one of the two major tributaries of the358

Aral Sea and drains an area of around 50,000 km². Our case study focuses on the headwaters of the basin, which359

originate in the Tianshan mountains. Snow and glacier melt are of great concern for the local population, as it provides360

water for energy and agriculture (Unger-Shayesteh et al., 2013; Gan et al., 2015). The parameters exposed concern361

First Author et al.: Preprint submitted to Elsevier Page 17 of 37

Short Title of the Article

Figure 5: Regions in the two case studies: on the left the Barton Springs Segment of the

Edwards Aquifer in Texas for MODFLOW, on the right the Naryn Basin in Kyrgyzstan for

SWAT.

snowmelt and snowfall (a full list is provided in Table 3). The choice is based on preliminary investigations that362

comprised a comprehensive sensitivity analysis and calibration of our SWAT model (Schaﬀhauser et al., 2023). These363

parameters (snowfall temperature, snowmelt temperature, maximum and minimum melt rate) proved to be among364

the most sensitive ones providing a reasonable model performance. The case study represents an example where the365

model is intended to be used by local authorities. Our conﬁguration provides an example of an abstraction that can366

be used by both non-experts and more experienced users. In this case, the non-experts will be decision-makers in367

an agricultural agency, while the more advanced users will be in the local water authority who will have a broader368

expertise in water-related questions. The model component shall ﬁnally be used by these decision-makers to examine369

the eﬀects of changes in snow processes on streamﬂow. Snow processes constitute the dominant source of water and370

serves as a proxy of water availability in spring for the region. An exploration of the timing and amount of snowmelt371

provides decision-makers with valuable insights on the available water for diﬀerent sectors, such as agriculture or372

First Author et al.: Preprint submitted to Elsevier Page 18 of 37

Short Title of the Article

Table 3

Summary of the two case studies, describing the main characteristics of the two case

studies. For case study 2, the abbreviations M-A, M-B and M-I refer to the three model

components based on average conditions with default pumping rates, a baseline consider-

ing drought conditions and a component where the user can specify pumping rates and

inﬁltration. Exposed parameters and input ﬁles indicate those elements highlighted by the

expert modeler for each scenario which can be customized by others.

Case Study 1 Case Study 2

Hydrological Model SWAT MODFLOW

Name of Model Conﬁguration Naryn - SWAT Barton Springs - MODFLOW

Region Naryn Basin, Kyrgyzstan Edwards Aquifer, Texas, US

Region Size 10,000 km² 401 km²

Scenario Summary Water resources management, ﬂoods, crop

yield, energy production

Sustainable yield, drought assessment,

evaluation of pumping rates under stress

conditions

Dominant Processes Snow and glacier related Inﬁltration, pumping

Exposed Parameters Snowmelt temperature, snowfall temperature,

max. melt factor summer, min. melt factor

winter

None

Exposed Input ﬁles basin.bsn Baseline model (M-B) & model with average

conditions (M-A): None, Inﬁltration model

(M-I): inﬁltration, pumping rates & recharge,

wells

Exposed Output Variables Streamﬂow Hydraulic head, total water storage, total

volume extracted

energy.373

This information is important in many aspects. For example, authorities can deduce how much water is expected374

to be available for agriculture. This enables an estimate of the expected yield within the crop season, one of the major375

economic factors for the region. In addition, this water is required to be stored for energy production of the whole376

country. Besides, the period is prone to ﬂoods, frequently causing at least local threats. By having model outputs377

of water availability, decision-makers can allocate water to diﬀerent purposes, advance or delay planting dates, and378

generally prepare for the speciﬁc seasonal requirements such as energy or irrigation demand.379

Accordingly, we share the model conﬁguration to enable these users to adjust the snow-related parameters, namely380

snowmelt temperature, snow fall temperature as well as the minimum and maximum snowmelt factors. Users can381

then explore their own scenarios, and monitor the actual conditions of the basin to assess which of their scenarios382

correspond to the actual conditions of the current season.383

To provide some initial scenarios, we provide a set of default values for all snow parameters to provide users with a384

starting point. As the response variable of interest for the end-user is discharge, only the corresponding output ﬁle385

is exposed in our component. For simplicity, we decided to predeﬁne all input ﬁles so that users cannot make any386

changes.387

First Author et al.: Preprint submitted to Elsevier Page 19 of 37

Short Title of the Article

5.3.3. Drought impact on the water budget in Barton Springs - Case Study388

The second study refers to the Edwards Aquifer and more precisely the Barton Springs segment in Austin, Texas,389

a region increasingly aﬀected by droughts (Passarello et al., 2012, 2014). A numerical simulation, using the MOD-390

FLOW model, was developed for use as a groundwater availability model (GAM) in the state of Texas (Scanlon et al.,391

2001, 2003).392

The MODFLOW conﬁguration was prepared as part of a state-wide planning activity. The components underwent393

a scientiﬁc vetting process to assess groundwater availability. The intended end users are groundwater managers for394

state-designated management districts, as well as stakeholders involved in the recurring groundwater aquifer man-395

agement program of the state of Texas. They are not hydrology experts necessarily, although they have expertise in396

groundwater. Water availability ﬂuctuates rapidly in the region, due to normal variability in weather and climate con-397

ditions. As urban areas have expanded in the past decade, water consumption has increased and habitats for vulnerable398

species are at greater risk for impact during dry conditions. Table 3) shows an overview of the models. We created a399

model component M-B that reﬂects a baseline model for drought conditions with default pumping rates. We created400

a separate component M-A for average conditions, also with default pumping rates. M-B was explicitly designed to401

investigate and emphasize potential adverse eﬀects of pumping under dry conditions. In contrast, M-A shows the im-402

pacts of similar pumping conditions under normal non-drought conditions. We also created a third component M-I403

where the user can specify inﬁltrated water (as a recharge input ﬁle) and pumping rates (as a wells input ﬁle). The404

components are designed to expose key model outputs concerning water table levels (hds output ﬁle representing hy-405

draulic head levels), storage (cbb output ﬁle representing volumes), and actual pumping rates (cbb output ﬁle).406

The recharge zones were developed for Barton Springs GAM because it represents a baseline interpretation of ground-407

water behavior, the model is readily accessible. The recharge zones were originally completed as part of a Groundwater408

Decision Support System developed to assess the sustainable yield (Pierce et al., 2006; Pierce, 2006).409

5.3.4. Model Encapsulation410

The following subsections demonstrate the model encapsulation of each case study. A summarized overview of411

the steps and the diﬀerences in the procedure (where users have to perform manual adaptions) for each case study, is412

shown in Table 4. The encapsulation process follows the model preparation steps (usually including calibration and413

validation) which are performed by the expert modeler.414

5.3.4.1. STEP 1: Start New Environment An environment has to be created for each model conﬁguration (see415

Section 2.3). For case study 1, the modeler would create a single model component focused on the snow processes416

of SWAT. For case study 2, the modeler chose to create three separate model components: one for baseline drought417

conditions, one for baseline average conditions, and a third one for analyzing diﬀerent scenarios in average conditions.418

First Author et al.: Preprint submitted to Elsevier Page 20 of 37

Short Title of the Article

Table 4

Overview of the steps conducted in MINT for the dissemination of the two case studies.

We highlight where users have to incorporate manual modiﬁcations and which explicit

setting we made in our example.

SWAT MODFLOW

1) Start New environment no diﬀerence except name of the model

conﬁguration

no diﬀerence except name of the model

conﬁguration

2) Trace Execution Dependencies execution command is model-speciﬁc

./swat670

execution command is model-speciﬁc ./mf6

3) Expose Parameters MIC command (mic pkg parameters),

parameters are model and case speciﬁc,

here: snowfall temperature, snowmelt

temperature, maximum & minimum melt

rate

MIC command (mic pkg parameters),

parameters are model and case speciﬁc, here:

none adjustable parameter deﬁned

4a) Expose Input Files MIC command (mic pkg inputs), desired

input ﬁles to share are model and case

speciﬁc, in this case basins.bsn

MIC command (mic pkg inputs), desired

input ﬁles to share are model and case speciﬁc

4b) Expose Output Files MIC command (mic pkg outputs), desired

output ﬁles to share are model and case

speciﬁc, in this case reach.rch

MIC command (mic pkg outputs), desired

output ﬁles to share are model and case

speciﬁc, in this case .hds, .lst

5) Create Wrapper Script MIC command (mic pkg wrapper, mic pkg

run), manual & model-speciﬁc adaptions

when default parameter changes are

desired

MIC command (mic pkg wrapper, mic pkg

run), manual & model-speciﬁc adaptions

when default parameter changes are desired

6) Model Upload MIC command (mic pkg upload),

automatically uploads the model

conﬁguration to DockerHub, GitHub and

MINT

MIC command (mic pkg upload),

automatically uploads the model

conﬁguration to DockerHub, GitHub and

MINT Model Catalog

The modeler starts MIC from the command line, where he provides the name of the model conﬁguration. In our case,419

the names are Naryn - SWAT and Barton Springs - MODFLOW 1 to 3. MIC automatically creates the folder structure420

for each model conﬁguration.421

5.3.4.2. STEP 2: Trace Execution Dependencies The modeler then does a test run to check if the respective422

model is installed in a new environment and to trace the execution dependencies. Then, MIC is used to trace input and423

output dependencies (through ReproZip). Since MIC is a Unix-based tool, the invocation command for SWAT refers424

to the Unix-based execution ﬁle, which can be downloaded via the SWAT homepage.

As for MODFLOW, we used425

the Python-based FloPy tool for the model encapsulation.

FloPy serves as a tool which is used to execute existing426

MODFLOW-based models.427

5.3.4.3. STEPS 3 & 4: Expose Parameters, Inputs and Outputs For the SWAT model conﬁguration, several428

snow parameters were exposed, which were snowfall temperature, snowmelt temperature and the maximum and min-429

https://swat.tamu.edu/software/swat-executables/

https://www.usgs.gov/software/flopy-python-package-creating-running-and-post-processing-modflow-b ased-mo

dels

First Author et al.: Preprint submitted to Elsevier Page 21 of 37

Short Title of the Article

imum melt factors. The parameter selection was based on a preliminary study done by the modeler with relevant430

stakeholders to identify the dominant parameters (see also Table 3). Each parameter exposed must be manually spec-431

iﬁed in MIC, as described in Section 4. Subsequently, the parameters must be indicated in the corresponding SWAT432

input ﬁles (as shown in Figure 2). Adjustments of default parameter values are possible during this step as well. Next,433

the modeler declares the input ﬁles that contain the exposed parameters as conﬁguration ﬁles. Since all snow parame-434

ters of SWAT are stored in the basin ﬁle (basin.bsn), it is the only conﬁguration ﬁle relevant to the model conﬁguration.435

The users in the Naryn case study, such as authorities related to the agricultural, energy or water sector, do not need436

all the output ﬁles so only the output.rch ﬁle is exposed, as it contains all required information on streamﬂow within437

the basin.438

For the conﬁgurations of the MODFLOW model in case study 2 no parameters were exposed. For the drought model439

component only the .hds and .lst input ﬁles were exposed, where the relevant information of the hydraulic head and440

the water budget can be speciﬁed by users.441

5.3.4.4. STEP 5: Create Wrapper Script MIC helps wrap model conﬁgurations by taking into account the ex-442

ecution settings and prepares the ﬁles to test the model components. The test runs done by MIC were based on the443

default parameter settings deﬁned in the previous step and double-checked manually. After the test run, the model444

conﬁguration was ﬁnalized and ready for upload.445

5.3.4.5. STEP 6: Model Upload Finally, MIC uploads the model conﬁgurations to relevant repositories. The446

Docker image of the model component was uploaded to DockerHub.

6 7

A GitHub repository containing the input447

data and results was also created

. Finally, an entry in the MINT model catalog was created,

9 10

and the model can be448

easily run from the MINT user interface.449

6. Scenario Exploration by Non-Expert Users with New Model Conﬁgurations450

This section describes how users can access the newly created model conﬁgurations of the two case studies. It451

highlights how users can easily specify simulation scenarios using the model conﬁgurations.452

6.1. Accessing Model Components453

Users can browse all model conﬁgurations, for example by bringing up the corresponding regions, Kyrgyzstan454

and Texas, or browsing entries in the MINT model catalog. Typically, a user starts in the “Use Models" tab, and455

https://hub.docker.com/r/mosorio/naryn_nival_setup/tags

https://hub.docker.com/r/mintproject/modﬂow-2005/tags

Components are archived in Zenodo: https://zenodo.org/record/6948339.Yue0VHZByMq

https://mint.isi.edu/kyrgyzstan/models/explore/SWAT/8cc84426-d849-471b-9a5e -4 7bcaf094607/6a36a2e5-73bf-4

098-9acd-1aaaab383d4a/14580635-c7ca-4256-935a-4ddbdacfbfe2

htt ps:/ /mint.is i.ed u/te xas/mode ls/e xplore/M ODFL OW/m odflow_20 05/m odflow_20 05_cf g/modflo w_20 05_Ba rtonSpri n

gs_avg

First Author et al.: Preprint submitted to Elsevier Page 22 of 37

Short Title of the Article

Figure 6: Illustration how the two case studies can be accessed within the MINT modeling

framework, each shown on the left and right sides of the ﬁgure. The upper panels refer

to the selection of the study area from a map. The lower panels show the corresponding

problem statements that drive the set up and execution of the model conﬁgurations.

speciﬁes a problem statement by selecting a time period for the simulation, a region of interest, and desired response456

variables (i.e., simulation outputs). Once the problem statement is speciﬁed, MINT will show the user relevant model457

conﬁgurations that can be run. Fig. 6 shows the MINT user interface to access model conﬁgurations in the diﬀerent458

regions. More details are provided in the next section.459

6.2. Model, Dataset & Parameter Selection460

The Naryn case study aims to simulate discharge by adjusting the snow parameters that govern the predominant461

processes in the region. In detail, these processes involve snowmelt and snowfall and therefore the snowpack distribu-462

tion in the region. These processes control discharge generation. Thus, a task was created where river discharge was463

used as response variable. As shown in Figure 7 a), it would also be possible to use other models to obtain discharge,464

such as TopoFlow (Peckham, 2009). A similar overview for the Barton Springs case study is provided in Figure 8.465

First Author et al.: Preprint submitted to Elsevier Page 23 of 37

Short Title of the Article

Figure 7: Illustration of: a) available model components for the simulation of discharge

for the Naryn case study; b) the snow parameter modiﬁcation of our model within the

problem statement and task section of MINT, exempliﬁed at the Naryn case study. It is

demonstrated how the four exposed snow parameters are predeﬁned with default values,

that can be directly adjusted here.

First Author et al.: Preprint submitted to Elsevier Page 24 of 37

Short Title of the Article

Figure 8: Illustration of: a) available model components for the drought assessment of the

Barton Spring case study. b) the parameter modiﬁcation of our model within the problem

statement and task section of MINT, again exempliﬁed at the case study of the Barton

Springs. Due to the static design, no parameters can be adjusted, but the model can

simply be run with the default parameter values.

Multiple model components may be selected, which would allow users to easily create a model ensemble to provide466

a more diﬀerentiated picture. At this point the user would choose among all available input datasets, such as mete-467

orological information with precipitation and temperature. An example can be found in Appendix A1 where users468

can choose between two alternative well ﬁles (with diﬀerent pumping rates) for the Barton Springs area, which would469

allow them to evaluate the eﬀects on the groundwater levels under various pumping rates.470

Users can also easily specify diﬀerent parameter values to reﬂect diﬀerent scenarios or assumptions. As described in471

First Author et al.: Preprint submitted to Elsevier Page 25 of 37

Short Title of the Article

Section 5.3.2, four snow parameters were exposed and the user can assign them diﬀerent values to explore diﬀerent472

scenarios, as shown in Figure 7 b). This allows users to explore diﬀerent dates for the onset of the snowmelt season,473

represented by various temperature thresholds. If users provide several values, MINT runs the model multiple times.474

All outputs are provided individually for each run. In the parameter tab (Figure 7 b) users can also check the default475

values of each parameter. This is particularly relevant if the default values are based on expert knowledge and refer to476

a speciﬁc baseline which can be used for the comparison with developed scenarios. The static design of the Barton477

Springs components does not allow for any parameter changes, thus the corresponding tab is empty (see Figure 8 b).478

6.3. Execute & Analyze Model Components479

When users set parameter values, the model component can be executed and the “Results" tab in MINT provides a480

summary of all the outputs. In the Naryn use case, the outputs were limited to the output.rch ﬁle where the discharge481

information is stored. The results represent the discharge response to the adjusted snow dynamics in the basin, which482

were compared with the baseline simulation results obtained with the default parameter values (no shift). For every483

parameter combination a model run was executed and the corresponding outputs were generated. An example is shown484

in Appendix A2, where the user speciﬁed two values for each of the four parameters which led to 16 combinations485

each resulting in an execution and each with its output ﬁles. To eliminate unnecessary computations, MINT caches486

the results of executions.487

MINT can generate some standard visualizations, but users often generate their own custom visualizations after

Figure 9: Results of the discharge simulation with the SWAT case study when the scenario is run (green line), compared

to the default setup (black line). The ﬁgure indicates the seasonal shift towards an early melt onset under changing

conditions. The example intends to show what future versions of MINT could directly visualize. The lines represent a

mean over ﬁve years for each Julian Day.

488

downloading the results in a post-processing step. We show a visualization of the results from the SWAT case study489

First Author et al.: Preprint submitted to Elsevier Page 26 of 37

Short Title of the Article

comparing a particular scenario versus the baseline in Figure 9. Users can now directly derive the desired information,490

depending on how strong the average shift in river discharge would be under changing snow conditions. The results491

shown in the ﬁgure represent the mean of a ﬁve-year period. From the plot it becomes apparent that the conditions492

represented by the scenario would lead to a strong rise in discharge in early March already. Besides, the earlier onset493

and steep rise of snowmelt would cause higher discharge in April and May compared to the baseline, while it would be494

reduced during the summer months. The annual peak would already occur 1.5-2 months earlier than in the baseline.495

This signiﬁcant change in the ﬂow regime may have far-reaching consequences for the water sector. For example, the496

summer reduction may aﬀect agricultural production as irrigation water is missing, while the strong increase after the497

winter months may promote the damage potential of ﬂood events. Ultimately, water authorities may conclude to assess498

the potential of a reservoir to mitigate those undesired eﬀects.499

For the second case study, we declared a problem statement where we included the diﬀerent Barton Springs model500

components. To access the model conﬁgurations, the study area in MINT has ﬁrst to be changed to Texas (analogously501

to Fig. 6), where we can then select Barton Springs - MODFLOW. Users can create tasks, which reﬂect a speciﬁc502

scenario, and select an appropriate model conﬁguration. One of the scenarios may focus on drought assessment,503

using the M-B conﬁguration. Another task may be for average conditions, using the M-A conﬁguration. A third task504

may focus on the impacts of speciﬁc recharge and pumping conditions, using the M-I conﬁguration. Users have the505

possibility to compare the three diﬀerent setups and easily analyze the diﬀerences in groundwater availability in the506

region. In detail, one can evaluate the eﬀects of pumping on groundwater levels and study how the aquifer should507

be managed to maintain ﬂow under speciﬁc conditions. Users might infer that, under drought conditions, pumping508

alone is not suﬃcient. In contrast to the SWAT model conﬁguration, where only one output ﬁle is accessible, the509

MODFLOW model conﬁgurations oﬀer four diﬀerent output ﬁles.510

It is worth noting that the application of the scenarios does not require any computing/programming skills for users.511

However, if users want to run encapsulated models locally, basic container skills are required. In general this is seldom512

the case, since MINT relies on user-friendly GUI (Fig. 6 and 8).513

7. Discussion514

Models created by experts are usually diﬃcult to use by modelers in other disciplines. Despite the need by decision-515

makers to access sophisticated models, they remain inaccessible to non-experts (Bagstad et al., 2013). Even experts516

within a discipline ﬁnd that it takes signiﬁcant eﬀort to setup and compare models from other modelers (Lüke and517

Hack, 2018; Francesconi et al., 2016). Our work shows that two very diﬀerent hydrological models could be encapsu-518

lated using the same methodology to simplify model dissemination by experts for use by non-experts. Our MIC tool519

can be used by expert modelers without major knowledge of software engineering (e.g., using software containers,520

First Author et al.: Preprint submitted to Elsevier Page 27 of 37

Short Title of the Article

managing execution dependencies, or setting up code repositories). We demonstrated the methodology for diﬀerent521

model domains, purposes, technical details, and model structures.522

Our case studies illustrate that modelers only have to determine the parameters and input and output ﬁles to be523

exposed, according to the intended scenarios. Diﬀerent uses of a model (e.g., snow-related analysis or studies focusing524

on crop yield) lead to diﬀerent model conﬁgurations and are organized and easily accessible in MINT. The methodology525

enables expert modelers to create useful abstractions of existing models. The abstraction hides the part of the model526

complexity that is not necessarily required for the target users. Therefore, once a model has been encapsulated with527

our methodology, non-expert users are relieved from dealing with the technical details of the model execution or its528

structure.529

Diﬀerent types of non-experts may beneﬁt from our eﬀort, depending on their expertise and background. For530

example, citizens of hydrological extremes (drought and ﬂoods), who become relevant stakeholders and develop a531

certain level of expertise to understand their own scenarios; NGO members who are interested in model applications532

in the environmental sector; or decision makers who usually have a decent hydrological know-how, but may not be533

familiar with modeling (water authorities are often busy with administrative work, which means that there is little time534

for the construction and calibration of complex models). Additionally, we envision expert modelers to beneﬁt from535

this eﬀort, as it facilitates the creation of model ensembles for model comparisons or for benchmarking.536

Our methodology may be used to share and use pre-agreed scenarios (as in our Barton Springs case study), and537

support users developing their own scenarios independently by modifying the exposed parameters. We also included538

the possibility of exposing input datasets in model conﬁgurations so users can select their own. For example, several539

meteorological data sets may be used for the execution of a model conﬁguration. Processing all required input data540

is time-consuming and HMs often have diﬀerent requirements. Exchanging these data often represents an obstacle541

(Gardner et al., 2018) that can be at least partially overcome by using MINT. Modelers are also encouraged to describe542

their conﬁgurations with metadata so that users can search ﬂexibly for models and use those that are suitable for their543

scenarios. A region-speciﬁc search (which corresponds to Kyrgyzstan or Texas in our examples) allows users ﬁnding544

all available models for that region. Modelers should also provide code for output visualizations (see Section 6.3).545

The integration of a general visualization environment in MINT would facilitate the usability in extended scenarios,546

for example by integrating other datasets that may be relevant to the modeling scenarios (e.g., population density, road547

access, etc.).548

Although the examples of this paper focus on hydrological models, our methodology has been applied to models549

in other domains, including agriculture and economics. We assume all encapsulated models to be open source, or have550

an open source executable that can be shared in a software container.551

This methodology helps aligning a software component with the ﬁndable, accessible, interoperable, and reusable552

First Author et al.: Preprint submitted to Elsevier Page 28 of 37

Short Title of the Article

principles (FAIR) for data (Wilkinson et al., 2016), following current best practices for Open Science. By creating553

software components that have speciﬁc functionality and clear invocation and results, modelers provide self-contained554

and pre-prepared model components that are well characterized and become easier to reuse than the original modeling555

software. Model components are more accessible than the original modeling software as they are encapsulated in556

a software container that can be executed in any platform. Model components include extensive machine-readable557

software metadata that makes them more ﬁndable and interoperable.558

Finally, it is worth noting that we used pre-calibrated models for our case studies. Future work will address this559

limitation by integrating model calibration capabilities into our framework and methodology.560

8. Conclusions561

This paper introduced a methodology to simplify the dissemination of expert models to non-expert users. The562

methodology guides modeling experts when creating software components that explore speciﬁc modeling scenarios.563

The methodology is applicable to any kind of model, regardless of its discipline, processes or technical details. The564

implementation of the methodology in the MIC tool enables a simple model encapsulation process for modelers.565

This does not only facilitate model dissemination and provision, but can also improve mutual work within or across566

disciplines and groups. In addition, the complexity of the model can be simpliﬁed by creating model conﬁgurations that567

suit the needs of non-expert users. Our proposed methodology thus creates new possibilities in model abstractions and568

promotes the satisfaction of end-user needs. This is also supported by the easy access options of model conﬁgurations569

in MINT, which greatly simpliﬁes their (re)use.570

We illustrated our methodology with two case studies, using two diﬀerent hydrological models in two diﬀerent re-571

gions of the world. The case studies provide examples how potential scenarios and use cases for the application of the572

methodology could look like. However, the universal applicability of the methodology within any modeling discipline573

enables a free design of scenarios with numerous potential use cases that can help both, the expert modeler as well574

as the end-user. MINT users can easily compare the eﬀects of pumpage under diﬀerent conditions on groundwater575

levels. Moreover, they can infer whether pumping is suitable to maintain ﬂow under drought conditions or if additional576

measures should be taken into account. Additionally, we showed how a restriction of the parameter space to a useful577

minimum can facilitate the exploration of discharge shifts by decision-makers. The methodology encourages the pos-578

sibility of independently investigating scenarios and to derive valuable insights. For example, resulting discharge shifts579

may lead to several consequences for the water sector, e.g., increased ﬂood risk or decreased agricultural production580

to mention only two out of dozens, that call for action.581

Our work supports the FAIR principles, helping model components to be more ﬁndable, accessible, interoperable582

and reusable. However, our methodology also presents some limitations, which are part of our future work. For583

First Author et al.: Preprint submitted to Elsevier Page 29 of 37

Short Title of the Article

example, while our methodology helps non-experts executing models created by expert modelers, some expertise is584

still needed to interpret the results of the simulations. In some cases this is addressed by adding documentation and585

metadata in the scenario, in order to provide the right context for end users. In other cases, expert modelers include ad-586

hoc visualizations that are executed with the model itself, helping to interpret the outputs. Extending our methodology587

to ensure that visualization components are described for each model output would help address this issue. We are also588

exploring extending MINT with general-purpose visualizations (e.g., variables obtained in tabular model results).589

Another point of improvement involves expanding the supported actions for modeling experts in MINT. For ex-590

ample, including additional data transformations and model calibration (right now models are calibrated by experts591

independently).592

Finally, additional case studies in other domains are part of our future work in order to further reﬁne the applicability593

of our approach when disseminating models across disciplines, lowering the barrier of adoption of models by modeling594

experts.595

Software and Data Availability596

Name of the software: Model component 1 - Snow dynamics597

Developer: Timo Schaﬀhauser (t.schaﬀhauser@tum.de), Maximiliano Osorio (mosorio@isi.edu)598

Software availability: https://hub.docker.com/r/mosorio/naryn_nival_setup/tags (Docker image)599

Compressed size: 286.97 MB (Docker image)600

601

Name of the software: Model component 2 - Drought impact602

Developer: Suzanne Pierce (spierce@tacc.utexas.edu), Maximiliano Osorio (mosorio@isi.edu)603

Software availability: https://hub.docker.com/r/mintproject/modflow-2005/tags (Docker image)604

Compressed size: 733.55 MB (Docker image)605

606

Name of the software: Model Insertion Checker (MIC)607

Developer: Maximiliano Osorio (mosorio@isi.edu)608

Software availability: https://zenodo.org/record/6024985}.YvPflnZByMo/609

Programming language: Python610

Compressed size: 19.9 MB611

612

Name of the dataset: SWAT & MODFLOW Model Components613

Developer: Timo Schaﬀhauser (t.schaﬀhauser@tum.de), Daniel Garijo, Maximiliano Osorio, Daniel Bittner, Suzanne614

First Author et al.: Preprint submitted to Elsevier Page 30 of 37

Short Title of the Article

Pierce, Hernan Vargas, Markus Disse, Yolanda Gil615

Data availability: https://zenodo.org/record/6948339}.YvJ6V3ZByMr616

Form of repository: Zenodo archive617

Compressed size: 51.7 MB618

619

Further access to the model components is possible via https://mint.isi.edu/kyrgyzstan/models/explo620

re/SWAT/8cc84426-d849-471b-9a5e-47b caf094607/6a 36a2e5-73bf-4098-9acd-1aaaab383d4a/145 806621

35-c7 ca-4256-935a-4ddbdacfbfe2 and https://mint.isi. edu/t exas/models/explore/MODFLOW/modf622

low_2005/modflow_2005_cfg/modflow_2005_BartonSprings_avg.623

Acknowledgements624

We would like to thank our collaborators in the MINT project, particularly modeling experts and users that con-625

tributed to the design of the overall MINT framework. We gratefully acknowledge support from the US Defense Ad-626

vanced Research Projects Agency through award W911NF-18-1-0027 and the US Oﬃce of Naval Research through627

award N00014-21-1-2437. The authors from TUM also want to thank the BMBF (Bundesministerium für Bildung628

und Forschung) for the funding of the "OekoFlussPlan" project (grant number 01LZ1802B). The author from UPM629

has been supported by the Madrid Government (Comunidad de Madrid-Spain) under the Multiannual Agreement with630

Universidad Politécnica de Madrid in the line Support for R&D projects for Beatriz Galindo researchers, in the context631

of the V PRICIT (Regional Programme of Research and Technological Innovation) and the call Research Grants for632

Young Investigators from Universidad Politécnica de Madrid.633

First Author et al.: Preprint submitted to Elsevier Page 31 of 37

Short Title of the Article

Appendices634

A1635

Figure A1: Illustration of the selection of diﬀerent input datasets for the well ﬁles. For the Barton Springs case study users

would have two possibilities in that case.

First Author et al.: Preprint submitted to Elsevier Page 32 of 37

Short Title of the Article

A2636

Figure A2: Example of: a) in total 16 diﬀerent runs of the model component, since for all exposed parameters two diﬀerent

values were set; and b) the corresponding 16 output ﬁles, which were generated through running the component with all

16 potential parameter value combinations.

First Author et al.: Preprint submitted to Elsevier Page 33 of 37

Short Title of the Article

References637

Andreu, J., Capilla, J., Sanchís, E., 1996. AQUATOOL, a generalized decision-support system for water-resources planning and operational man-638

agement. Journal of Hydrology 177, 269–291. doi:10.1016/0022-1694(95/02963-x.639

Arnold, J.G., Fohrer, N., 2005. SWAT2000: current capabilities and research opportunities in applied watershed modelling. Hydrological Processes640

19, 563–572. doi:10.1002/hyp.5611.641

Arnold, J.G., Srinivasan, R., Muttiah, R.S., Williams, J.R., 1998. LARGE AREA HYDROLOGIC MODELING AND ASSESSMENT PART i:642

MODEL DEVELOPMENT. Journal of the American Water Resources Association 34, 73–89. doi:10.1111/j.1752-1688.1998.tb05961.x.643

Bagstad, K.J., Semmens, D.J., Waage, S., Winthrop, R., 2013. A comparative assessment of decision-support tools for ecosystem services quantiﬁ-644

cation and valuation. Ecosystem Services 5, 27–39. doi:10.1016/j.ecoser.2013.07.004.645

Bernstein, B.B., Thompson, B.E., Smith, R.W., 1993. A combined science and management framework for developing regional monitoring objec-646

tives. Coastal Management 21, 185–195. doi:10.1080/08920759309362202.647

Bittner, D., Narany, T.S., Kohl, B., Disse, M., Chiogna, G., 2018. Modeling the hydrological impact of land use change in a dolomite-dominated648

karst system. Journal of Hydrology 567, 267–279.649

Bittner, D., Rychlik, A., Klöﬀel, T., Leuteritz, A., Disse, M., Chiogna, G., 2020. A gis-based model for simulating the hydrological eﬀects of land650

use changes on karst systems–the integration of the lukars model into freewat. Environmental Modelling & Software 127, 104682.651

Boettiger, C., 2015. An introduction to docker for reproducible research. ACM SIGOPS Operating Systems Review 49, 71–79.652

Booij, M.J., Krol, M.S., 2010. Balance between calibration objectives in a conceptual hydrological model. Hydrological Sciences Journal–Journal653

des Sciences Hydrologiques 55, 1017–1032.654

Bradshaw, G.A., Borchers, J., 2000. Uncertainty as information: Narrowing the science-policy gap. Conservation Ecology 4.655

Brocca, L., Ciabatta, L., Massari, C., Camici, S., Tarpanelli, A., 2017. Soil moisture for hydrological applications: Open questions and new656

opportunities. Water 9, 140.657

Brunner, P., Simmons, C.T., 2012. Hydrogeosphere: a fully integrated, physically based hydrological model. Groundwater 50, 170–176.658

Collins, N., Theurich, G., DeLuca, C., Suarez, M., Trayanov, A., Balaji, V., Li, P., Yang, W., Hill, C., da Silva, A., 2005. Design and implementation659

of components in the earth system modeling framework. The International Journal of High Performance Computing Applications 19, 341–350.660

doi:10.1177/1094342005056120.661

Döll, P., Kaspar, F., Lehner, B., 2003. A global hydrological model for deriving water availability indicators: model tuning and validation. Journal662

of Hydrology 270, 105–134. doi:10.1016/s0022-1694(02/00283-4.663

Fatichi, S., Vivoni, E.R., Ogden, F.L., Ivanov, V.Y., Mirus, B., Gochis, D., Downer, C.W., Camporese, M., Davison, J.H., Ebel, B., Jones, N., Kim,664

J., Mascaro, G., Niswonger, R., Restrepo, P., Rigon, R., Shen, C., Sulis, M., Tarboton, D., 2016. An overview of current applications, challenges,665

and future trends in distributed process-based models in hydrology. Journal of Hydrology 537, 45–60. doi:10.1016/j.jhydrol.2016.03.026.666

Francesconi, W., Srinivasan, R., Pérez-Miñana, E., Willcock, S.P., Quintero, M., 2016. Using the soil and water assessment tool (SWAT) to model667

ecosystem services: A systematic review. Journal of Hydrology 535, 625–636. doi:10.1016/j.jhydrol.2016.01.034.668

Gan, R., Luo, Y., Zuo, Q., Sun, L., 2015. Eﬀects of projected climate change on the glacier and runoﬀ generation in the naryn river basin, central669

asia. Journal of Hydrology 523, 240–251. URL: https://doi.org/10.1016/j.jhydrol.2015.01.057, doi:10.1016/j.jhydrol.2015670

.01.057.671

Gan, T., Tarboton, D.G., Dash, P., Gichamo, T.Z., Horsburgh, J.S., 2020. Integrating hydrologic modeling web services with online data sharing to672

prepare, store, and execute hydrologic models. Environmental Modelling & Software 130, 104731. doi:10.1016/j.envsoft.2020.104731.673

Gardner, M.A., Morton, C.G., Huntington, J.L., Niswonger, R.G., Henson, W.R., 2018. Input data processing tools for the integrated hydrologic674

First Author et al.: Preprint submitted to Elsevier Page 34 of 37

Short Title of the Article

model GSFLOW. Environmental Modelling & Software 109, 41–53. doi:10.1016/j.envsoft.2018.07.020.675

Garijo, D., Osorio, M., Khider, D., Ratnakar, V., Gil, Y., 2019. OKG-Soft: An Open Knowledge Graph with Machine Readable Scientiﬁc Software676

Metadata, in: 2019 15th International Conference on eScience (eScience), IEEE, San Diego, CA, USA. pp. 349–358. doi:10.1109/eScience677

.2019.00046.678

Gil, Y., Cobourn, K., Deelman, E., Duﬀy, C., da Silva, R.F., Kemanian, A., Knoblock, C.A., Kumar, V., Peckham, S., Carvalho, L., Chiang,679

Y.Y., Garijo, D., Khider, D., Khandelwal, A., Pham, M., Pujara, J., Ratnakar, V., Stoica, M., Vu, B., 2018. Mint: Model integration through680

knowledge-powered data and process composition, in: 9th International Congress on Environmental Modelling and Software.681

Gil, Y., Garijo, D., Khider, D., Knoblock, C.A., Ratnakar, V., Osorio, M., Vargas, H., Pham, M., Pujara, J., Shbita, B., Vu, B., Chiang, Y.Y.,682

Feldman, D., Lin, Y., Song, H., Kumar, V., Khandelwal, A., Steinbach, M., Tayal, K., Xu, S., Pierce, S.A., Pearson, L., Hardesty-Lewis, D.,683

Deelman, E., Silva, R.F.D., Mayani, R., Kemanian, A.R., Shi, Y., Leonard, L., Peckham, S., Stoica, M., Cobourn, K., Zhang, Z., Duﬀy, C., Shu,684

L., 2021. Artiﬁcial intelligence for modeling complex systems: Taming the complexity of expert models to improve decision making. ACM685

Trans. Interact. Intell. Syst. 11. doi:10.1145/3453172.686

Haasnoot, M., Middelkoop, H., Van Beek, E., Van Deursen, W., 2011. A method to develop sustainable water management strategies for an uncertain687

future. Sustainable Development 19, 369–381.688

Hanson, R.T., Boyce, S.E., Schmid, W., Hughes, J.D., Mehl, S.W., Leake, S.A., Maddock, T., Niswonger, R.G., 2014. One-water hydrologic ﬂow689

model (MODFLOW-OWHM). doi:10.3133/tm6a51.690

Harbaugh, A.W., 2005. MODFLOW-2005 : the u.s. geological survey modular ground-water model–the ground-water ﬂow process. doi:10.313691

3/tm6a16.692

Hattermann, F.F., Vetter, T., Breuer, L., Su, B., Daggupati, P., Donnelly, C., Fekete, B., Flörke, F., Gosling, S.N., Hoﬀmann, P., Liersch, S., Masaki,693

Y., Motovilov, Y., Müller, C., Samaniego, L., Stacke, T., Wada, Y., Yang, T., Krysnaova, V., 2018. Sources of uncertainty in hydrological climate694

impact assessment: a cross-scale study 13, 015006. doi:10.1088/1748-9326/aa9938.695

Hill, C., DeLuca, C., Balaji, Suarez, M., Silva, A.D., 2004. The architecture of the earth system modeling framework. Computing in Science &696

Engineering 6, 18–28. doi:10.1109/mcise.2004.1255817.697

Horsburgh, J.S., Morsy, M.M., Castronova, A.M., Goodall, J.L., Gan, T., Yi, H., Stealey, M.J., Tarboton, D.G., 2016. Hydroshare: Sharing diverse698

environmental data types and models as social objects with application to the hydrology domain. JAWRA Journal of the American Water699

Resources Association 52, 873–889.700

Keller, C.A., Long, M.S., Yantosca, R.M., Silva, A.M.D., Pawson, S., Jacob, D.J., 2014. HEMCO v1.0: a versatile, ESMF-compliant component701

for calculating emissions in atmospheric models. Geoscientiﬁc Model Development 7, 1409–1417. doi:10.5194/gmd-7-1409-2014.702

Kinzelbach, W., Wang, H., Li, Y., Wang, L., Li, N., 2021. Decision support for local water authorities in guantao, in: Springer Water. Springer703

Singapore, pp. 77–136. URL: https://doi.org/10.1007/978-981-16-5843-3_4, doi:10.1007/978-981-16-5843-3_4.704

Koltsida, E., Kallioras, A., 2019. Groundwater ﬂow simulation through the application of the FREEWAT modeling platform. Journal of Hydroin-705

formatics 21, 812–833. URL: https://doi.org/10.2166/hydro.2019.040, doi:10.2166/hydro.2019.040.706

Konikow, L.F., 2010. The secret to successful solute-transport modeling. Ground Water 49, 144–159. URL: h tt p s : // d o i. o r g/ 1 0 .1 1 1 1 /j . 1 7707

45-6584.2010.00764.x, doi:10.1111/j.1745-6584.2010.00764.x.708

Krysanova, V., Hattermann, F.F., 2017. Intercomparison of climate change impacts in 12 large river basins: overview of methods and summary of709

results 141, 363–379. doi:10.1007/s10584-017-1919-y.710

Kurtzer, G.M., Sochat, V., Bauer, M.W., 2017. Singularity: Scientiﬁc containers for mobility of compute. PloS one 12, e0177459.711

Lautenbach, S., Berlekamp, J., Graf, N., Seppelt, R., Matthies, M., 2009. Scenario analysis and management options for sustainable river basin712

First Author et al.: Preprint submitted to Elsevier Page 35 of 37

Short Title of the Article

management: Application of the elbe DSS. Environmental Modelling & Software 24, 26–43. doi:10.1016/j.envsoft.2008.05.001.713

Lobanova, A., Liersch, S., Nunes, J.P., Didovets, I., Stagl, J., Huang, S., Koch, H., del Rocío Rivas López, M., Maule, C.F., Hattermann, F.,714

Krysanova, V., 2018. Hydrological impacts of moderate and high-end climate change across european river basins 18, 15–30. doi:10.1016/j.715

ejrh.2018.05.003.716

Lüke, A., Hack, J., 2018. Comparing the applicability of commonly used hydrological ecosystem services models for integrated decision-support.717

Sustainability 10, 346. doi:10.3390/su10020346.718

Merz, B., Hall, J., Disse, M., Schumann, A., 2010. Fluvial ﬂood risk management in a changing world. Natural Hazards and Earth System Sciences719

10, 509–527.720

Morales, T., Uriarte, J.A., Olazar, M., Antigüedad, I., Angulo, B., 2010. Solute transport modelling in karst conduits with slow zones during721

diﬀerent hydrologic conditions. Journal of Hydrology 390, 182–189. URL: https://doi.org/10.1016/j.jhydrol.2010.06.041,722

doi:10.1016/j.jhydrol.2010.06.041.723

Newman, A.J., Mizukami, N., Clark, M.P., Wood, A.W., Nijssen, B., Nearing, G., 2017. Benchmarking of a physically based hydrologic model.724

Journal of Hydrometeorology 18, 2215–2225.725

Osorio, M., Garijo, D., Heidelberg, C., Khider, D., hvarg, Dhruv, Rampin, R., Maurya, R., Gil, Y., 2022. mintproject/mic: 2.2.2. doi:10.5281/ze726

nodo.6024985.727

Overeem, I., Berlin, M.M., Syvitski, J.P., 2013. Strategies for integrated modeling: The community surface dynamics modeling system example.728

Environmental Modelling & Software 39, 314–321. doi:10.1016/j.envsoft.2012.01.012.729

Panagopoulos, A., 2022. Brine management (saline water & wastewater eﬄuents): Sustainable utilization and resource recovery strategy through730

minimal and zero liquid discharge (mld & zld) desalination systems. Chemical Engineering and Processing - Process Intensiﬁcation 176, 108944.731

doi:https://doi.org/10.1016/j.cep.2022.108944.732

Passarello, M.C., Pierce, S.A., Sharp, J.M., 2014. Uncertainty and urban water recharge for managing groundwater availability using decision733

support. Water Science and Technology 70, 1888–1896. doi:10.2166/wst.2014.437.734

Passarello, M.C., Sharp, J.M., Pierce, S.A., 2012. Estimating urban-induced artiﬁcial recharge: A case study for austin, TX. Environmental &735

Engineering Geoscience 18, 25–36. doi:10.2113/gseegeosci.18.1.25.736

Peckham, S., 2009. Chapter 25 geomorphometry and spatial hydrologic modelling, in: Developments in Soil Science. Elsevier, pp. 579–602. URL:737

https://doi.org/10.1016/s0166-2481(08/00025-1, doi:10.1016/s0166-2481(08/00025-1.738

Peckham, S., Syvitski, J., 2007. Evaluation of model coupling frameworks for use by the community surface dynamics modeling system (csdms).739

Peckham, S.D., Hutton, E.W., Norris, B., 2013. A component-based approach to integrated modeling in the geosciences: The design of CSDMS.740

Computers & Geosciences 53, 3–12. doi:10.1016/j.cageo.2012.04.002.741

Pezij, M., Augustijn, D.C., Hendriks, D.M., Hulscher, S.J., 2019. The role of evidence-based information in regional operational water management742

in the netherlands. Environmental Science & Policy 93, 75–82. doi:10.1016/j.envsci.2018.12.025.743

Pierce, S.A., 2006. Groundwater Decision Support: An integrated assessment linking causal narratives, numerical models, and combinatorial744

search techniques to determine available yield for an aquifer system. Ph.D. thesis. Jackson School of Geosciences, Department of Geology, The745

University of Texas at Austin.746

Pierce, S.A., Dulay, M.M., Sharp, J.M., Lowry, T.S., Tidwell, V.C., 2006. Deﬁning tenable groundwater management: Integrating stakeholder747

preferences, distributed parameter models, and systems dynamics to aid groundwater resource allocation. MODFLOW and More. International748

Groundwater Modeling Center, Golden, Colorado .749

Rampin, R., Chirigati, F., Shasha, D., Freire, J., Steeves, V., 2016. Reprozip: The reproducibility packer. Journal of Open Source Software 1, 107.750

First Author et al.: Preprint submitted to Elsevier Page 36 of 37

Short Title of the Article

Refsgaard, J.C., Storm, B., Clausen, T., 2010. Système hydrologique europeén (SHE): review and perspectives after 30 years development in751

distributed physically-based hydrological modelling. Hydrology Research 41, 355–377. doi:10.2166/nh.2010.009.752

Reinecke, R., Foglia, L., Mehl, S., Herman, J.D., Wachholz, A., Trautmann, T., Döll, P., 2019. Spatially distributed sensitivity of simulated global753

groundwater heads and ﬂows to hydraulic conductivity, groundwater recharge, and surface water body parameterization. Hydrology and Earth754

System Sciences 23, 4561–4582.755

Rossetto, R., Filippis, G.D., Borsi, I., Foglia, L., Cannata, M., Criollo, R., Vázquez-Suñé, E., 2018. Integrating free and open source tools and756

distributed modelling codes in GIS environment for data-based groundwater management. Environmental Modelling & Software 107, 210–230.757

doi:10.1016/j.envsoft.2018.06.007.758

Ruiz-Ortiz, V., García-López, S., Solera, A., Paredes, J., 2019. Contribution of decision support systems to water management improvement in759

basins with high evaporation in mediterranean climates. Hydrology Research 50, 1020–1036. doi:10.2166/nh.2019.014.760

Scanlon, B.R., Mace, R.E., Barrett, M.E., Smith, B.A., 2003. Can we simulate regional groundwater ﬂow in a karst system using equivalent porous761

media models? case study, barton springs edwards aquifer, USA. Journal of Hydrology 276, 137–158. doi:10.1016/s0022-1694(03/00064762

-7.763

Scanlon, B.R., Mace, R.E., Smith, B.A., Hovorka, S.D., Dutton, A.R., Reedy, R.C., 2001. Groundwater availability of the barton springs segment of764

the edwards aquifer, texas: Numerical simulations through 2050. The University of Texas at Austin, Bureau of Economic Geology, ﬁnal report765

prepared for the Lower Colorado River Authority .766

Schaﬀhauser, T., Lange, S., Tuo, Y., Disse, M., 2023. Shifted discharge and drier soils: Hydrological projections for a central asian catchment.767

Journal of Hydrology: Regional Studies 46, 101338. URL: https://www.sciencedirect.com/science /article/pii/S22145818230768

00253, doi:https://doi.org/10.1016/j.ejrh.2023.101338.769

Surﬂeet, C.G., Tullos, D., Chang, H., Jung, I.W., 2012. Selection of hydrologic modeling approaches for climate change assessment: A comparison770

of model scale and structures. Journal of Hydrology 464-465, 233–248. doi:10.1016/j.jhydrol.2012.07.012.771

Timmerman, J.G., Langaas, S., 2005. Water information: what is it good for? the use of information in transboundary water management. Regional772

Environmental Change 5, 177–187. doi:10.1007/s10113-004-0087-6.773

Unger-Shayesteh, K., Vorogushyn, S., Farinotti, D., Gafurov, A., Duethmann, D., Mandychev, A., Merz, B., 2013. What do we know about past774

changes in the water cycle of central asian headwaters? a review. Global and Planetary Change 110, 4–25. URL: https://doi.org/10.101775

6/j.gloplacha.2013.02.004, doi:10.1016/j.gloplacha.2013.02.004.776

US Army Corps of Engineers, 2000. Hydrologic modeling system HEC-HMS: technical reference manual. US Army Corps of Engineers, Hydrologic777

Engineering Center, Davis, CA.778

Wilkinson, M.D., Dumontier, M., Aalbersberg, I.J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.W., da Silva Santos, L.B., Bourne,779

P.E., Bouwman, J., Brookes, A.J., Clark, T., Crosas, M., Dillo, I., Dumon, O., Edmunds, S., Evelo, C.T., Finkers, R., Gonzalez-Beltran, A., Gray,780

A.J., Groth, P., Goble, C., Grethe, J.S., Heringa, J., ’t Hoen, P.A., Hooft, R., Kuhn, T., Kok, R., Kok, J., Lusher, S.J., Martone, M.E., Mons, A.,781

Packer, A.L., Persson, B., Rocca-Serra, P., Roos, M., van Schaik, R., Sansone, S.A., Schultes, E., Sengstag, T., Slater, T., Strawn, G., Swertz,782

M.A., Thompson, M., van der Lei, J., van Mulligen, E., Velterop, J., Waagmeester, A., Wittenburg, P., Wolstencroft, K., Zhao, J., Mons, B.,783

2016. The FAIR guiding principles for scientiﬁc data management and stewardship. Scientiﬁc Data 3. URL: https://doi.org/10.1038/sd784

ata.2016.18, doi:10.1038/sdata.2016.18.785

Zhang, K., Zargar, A., Achari, G., Islam, M.S., Sadiq, R., 2014. Application of decision support systems in water management. Environmental786

Reviews 22, 189–205. doi:10.1139/er-2013-0034.787

First Author et al.: Preprint submitted to Elsevier Page 37 of 37